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REMARKS 

Claims 14-30 (all pending claims) are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Miller et al. (US Patent 6,310,874 Bl, "Miller") in view of Ketchum et 
al. (US Patent 6,594,272, "Ketchum"). Claims 14-30 more accurately characterize the 
present invention as controlling the flooding of packets in bridged networks by looking 
for an association between a destination MAC address and a port, and if no port is 
found to be associated with the destination MAC address, then iteratively flooding for 
a first predetermined time and disallowing flooding for a second predetermined time 
until a port replies that it is associated with the destination MAC address. No such 
limitations are taught, suggested, or otherwise disclosed in Miller, or Ketchum. 

Applicant asserts that the Examiner has failed to make a prima facie showing of 
obviousness. The third requirement of an obviousness rejection under 35 USC 103^ as explicitly 
stated in MPEP 2143. that the prior art references must teach or suggest all the claim limitations. 

Even if Miller and Ketchum could be modified to perform in the manner stated by 
the Examiner, the Examiner has provided no motivation to do so as required by case law 
and the MPEP. See MPEP §2143. If the Examiner is claiming that such motivation 
would be commonly known in the art, Applicants challenge this assertion and demand 
evidence proving this as is required under §2144.03 of the MPEP. Otherwise, the 
rejection cannot be maintained. 

In the Final Office Action mailed 11/30/2004, Examiner states that Miller teaches 
until a reply is received from a port associated with the destination MAC address 
iteratively performing broadcast flooding for a first predetermined time period. 
Applicant respectfully traverses this assertion. Directing attention to Miller at FIG. 3, 
Miller does not teach flooding for a first predetermined time period. Flooding in Miller 
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continues UNTIL an address is found in a table (decision step 52). This is indicative of 
the problem the invention of the present application. There is no "predetermined time 
period" of this flooding in Miller; flooding only stops once an address is detected and 
thus continues indefinitely. While the Examiner cites col. 4, lines 61-66, that portion of 
Miller reads: 

The I/O ASIC then initiates a search of the address table to determine if the 
destination address contained in the header of the received data unit is listed in the 
address table as indicated by step 52. If the destination address is determined to be in 
the address table in step 52 then the data unit is transmitted to the destination device 
or devices as indicated by step 55. 

No portion of this cited text indicates any sort of predetermined flooding period; 
flooding continues UNTIL this condition is met. FURTHERMORE, the condition for the 
loop as cited in claim 14 in the present application is wholly distinct from Miller; Miller's 
flooding is based on an entry in a table rather than a reply received from a port. 

The Examiner also cites Miller at col. 5, lines 4-6 as anticipating this element of 
claim 14. However, Miller at col. 5 lines 4-6 reads: 

If the data unit is determined not to be a multicast data unit step 54 then the 
data unit is flooded as indicated by step 56 and flow returns to step 50. 
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Again, there is no overlap between this cited portion of Miller and the portion of 
claim 14 Examiner asserts it anticipates. There is no indication here of a predetermined 
flooding interval; flooding continues until a condition is met at step 52. 

Examiner asserts that the second limitation of claim 14 is disclosed by Ketchum, 
namely ceasing broadcast flooding of packets for a second predetermined time period. 
Applicant respectfully traverses this assertion as well. However, Ketchum makes no 
mention of ceasing flooding for a predetermined time period if no reply from a port 
associated with a destination MAC address is received. Directing attention the portion 
of Ketchum cited by the Examiner (col. 6, lines 52-61), Ketchum reads: 

A low-cost RF network implementation of the invention works using a store and forward 
mechanism. Each packet received by a node is re-transmitted to all adjacent nodes in range only 
once. This process floods the subnet or site with the contents of the packet, insuring that all nodes, 
including the intended recipient, will receive it. To avoid infinite loops due to this topology, such 
as due to the fact that nodes can hear each other and a given pair of nodes could transmit the 
same packet endlessly between each other, the de-looping feature of the invention is implemented. 

This portion of Ketchum does not teach the second limitation of claim 14, namely 
ceasing flooding for a predetermined time period if there is no reply from a port 
associated with a destination MAC address. "Ceasing for a predetermined time period" 
as claimed inherently indicates that there is a loop (as claimed in claim 14..."iteratively 
ceasing for a predetermined time period after flooding for a predetermined time period). 
Ketchum, on the other hand, is specifically focused on avoiding loops. 

Applicant respectfully asserts that all pending claims are currently patentable and 
requests Examiner to place the present application in condition for allowance. If there 
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are any matters the Examiner feels may be resolved by telephone, the Examiner is invited 
to call the undersigned attorney at the Examiner's earliest convenience. 

INVITATION TO TELEPHONE CONFERENCE 

In the event that the Examiner feels that there are remaining issues that may be resolved 
by telephone, the Examiner is invited to call the undersigned attorney at the telephone 
number listed below. 



Sierra Patent Group, Ltd. 
P.O. Box 6149 
Stateline, Nevada 89449 
Telephone: (775) 586-9500 



Date: January 31, 2005 
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